Application Deployment
In the field of enterprise application software, “deploy tools” are used to deploy a software application onto one or more destination computing systems such as a server or a cluster of servers. FIG. 1 provides an exemplary depiction of a deploy tool 103 that converts various source files stored on a data storage resource 101 (e.g., one or more hard disk drives) into an appropriate format for deployment on a server 113.
For ease of understanding FIG. 1 has been drawn so as to at least apply to a Java 2 Enterprise Edition (J2EE) environment which is recognized in the art as being a “component based” object-oriented environment. Component based software environments use granules of software (referred to as “components” or “component instances”) to perform basic functions. The functional granularity offered by a plurality of different components provides a platform for developing a multitude of more comprehensive tasks. Some examples of component based architectures besides J2EE include Common Object Request Broker Architecture (CORBA), Component Object Model (COM), Distributed Component Object Model (DCOM) and derivatives there from.
Assuming that the application whose source files are stored on the data storage resource 101 performs “back-end” business logic as well as provides some form of web interface (also referred to as a “web application”), the various source files within data storage resource 101 may include business logic source code designed to make use of business logic components (e.g., Enterprise Java Beans (EJBs) in the case of a J2EE environment) and web application source code designed to make use of web application components (e.g., pages, servlets, etc.). Here, the source files may include classfiles for creating the objects from which the application's components are constructed.
The various source files from which the application is constructed are passed to an archive builder 104. The archive builder 104 creates two separate archive files: 1) a first archive file (referred to as a .JAR file) that contains the application's business logic components; and, 2) a second archive file (referred to as a .WAR file) that contains the application's web application components. The .JAR and .WAR files are then combined into a third archive file (an enterprise archive file (.EAR)) file by an assembler 105. An archive file is a file that contains other files.
FIG. 1 depicts the contents of the .EAR file 106. Apart from the component contents within the .JAR and .WAR files 108, 109, the .EAR file 106 also includes an “application” deployment descriptor 107 (application.xml) and the .WAR file 109 contains a “web application” deployment descriptor 110 (web.xml). The role of the deployment descriptors 107, 109 are discussed in more detail further below in the immediately following section.
The .EAR file is sent to a deployer 111 by the assembler 105. The deployer analyzes the .EAR file and sends its various pieces to their appropriate destination(s). In the simple situation of FIG. 1, the contents of the .JAR file are sent to a bean container 115 and the contents of the .WAR file are sent to a web container 116. The server is assumed to have a base environment 114 that provides a number of base services 120 for the applications that are executed within the environment 114. For example, a security service may be one of the services associated with the base environment's set of services 120. In the case of J2EE, the base environment 114 is typically Java 2 Standard Edition (J2SE) and the base services 120 are those services provided by J2SE (e.g. “security” among others).
The containers 115, 116 themselves can be viewed as sub environments of the base environment 114 each having an additional layer of services 119 that exist “on top of” the services 119 associated with the base environment 120. In the case of J2EE, the environment of both containers 115, 116 is a J2EE environment and the additional layer of services 119 for each container are those provided by J2EE (e.g., Java Naming and Directory Interface (JNDI), Java Database Connectivity (JDBC), Java Messaging Service (JMS) among others).
Deployment Descriptors
A deployment descriptor is a text file associated with an application that contains configuration information for that application. Because text files can be easily created and modified, the inclusion of an application's configuration information into a text file allows different instances of the same application to be easily deployed with different configuration settings (e.g., a first set of configuration settings for a first deployment into a first server and a second set of configuration settings for a second deployment into a second server).
In order to set the desired configuration for any deployment situation, the possible content and format of the deployment descriptor needs to be predefined before beforehand. As such, the possible substance and manner of organization of a deployment descriptor (a format referred to as the deployment descriptor's “document type definition” (DTD)) is purposely defined so that the deployment environment is able to read and understand the information contained in the deployment descriptors 107, 110.
For example, in the case of J2EE, the DTD for the application level deployment descriptor 107 is defined in Java™ 2 Platform, Enterprise Edition Specification Version 1.3. Copyright 1999-2000, Sun Microsystems, Inc. Available at http://java.sun.com/j2ee/docs.html (hereinafter referred to as “the J2EE specification”); and, the DTD for the web application deployment descriptor 110 is defined in Java™ Servlet Specification, Version 2.3. Copyright 1998-2000, Sun Microsystems, Inc. Available at http://java.sun.com/products/servlet. FIG. 2 shows respective depictions 207, 210 of both of these J2EE DTDs. Because these J2EE DTDs 207, 210 are well understood they need not be thoroughly reviewed here in detail. However, some review is appropriate so that a basic understanding can be readily gained.
With respect to the application J2EE DTD 207, note that this DTD 207 allocates for configuration information that pertains to: 1) the displayed name of the application 220; 2) a human readable description of the application 221; 3) the displayed icon for the application 222; 4) a list of the application's bean components 223, web components 224, and application client components 225; and, 5) a list of security roles defined for that application 226.
With respect to the web application J2EE DTD 210, note that this DTD allocates for configuration information that pertains to, among other things: 1) the displayed name of the application's web interface (also referred to as its “web application”) 227; 2) a list of the web application's servlets 228; 3) a list of the mappings between servlets identified in 2) above and URL patterns for them 229; and, 4) whether or not the web application might call upon a bean component in order to execute its functions 230. Note that just some of the possible configuration items that may be found in a J2EE DTD are shown in application.xml 207 and web.xml 210 of FIG. 2 (i.e., the J2EE specification provides for more features than those observed in FIG. 2).
The DTD's 207, 210 as described above are defined by the J2EE Specification. Nevertheless it may be useful in at least some situations to configure with deployment descriptors certain parameters of an application other than those parameters specifically allocated for by the J2EE specification's DTDs.